如何为您的应用选择开发供应商：启动篇
作者 / Google 开发者关系主管 Rupert Whitehead
欢迎来到本次连载的最后一篇文章，我将在本文介绍一些最佳实践，帮助您把项目带上路，并最终走向成功。如果您觉得对之前的环节不太了解，请回顾与开发供应商合作的基础篇和选择篇。
着手去做
您对项目的筹备和启动方式可能会对其成功产生重大影响。想要把事情做好，就要确保您在组织中要拥有正确的技能和方法，事先与众人分享愿景和流程，并就工作环境的细节进行一些思考。在某些情况下，您可能会同时与多个供应商合作，因此我们也会就这方面的问题提出一些您需要考虑的事项。
在您的团队内部打好基础
有人觉得，请供应商来开发应用意味着，自己只需要坐下来等待成品交付就行了，但这种情况很少发生——假如您希望他们按时交付高质量应用的话。至少，您需要测试并接收供应商提交的产品，因此需要拥有能够执行验收测试的相关资源。我们建议您参与到项目的各个方面中去，从用户界面设计到营销，以及对已发布应用的维护支持。这都有助于确保应用满足您的业务需求。
因此，您需要确定您所在的组织需要拥有哪些技能才能满足您的项目要求，并制定相应计划以弥补可能存在的差距。为此，请向供应商提出下面的问题:
他们希望您为项目完成的任务有哪些。
他们认为您需要哪些技能才能完成这些任务。
为了方便您进入相应的角色，他们可能提供或推荐哪些培训服务。
随后，要评估您所在组织的能力，请问自己:
您的营销部门是否熟悉 Google 在推广应用方面的最佳实践？对商店产品详情页面实验有没有详细的认知？
您是否具备设计和文案方面的技能，是否能够完成出色的设计、制作相应的屏幕截图，并用美妙的文案在 Play 商店描述产品？
确保所有人步调一致
开发供应商的选择并非一日之功，所以甲乙双方所在的组织里的每一个人对项目进度了解的情况都会多少存在落差，所以您需要确保所有人步调一致。请在项目开始时准备启动简报 (Kick-off Briefing)，并让每一个人参加——包括您所在组织的员工和供应商的员工—— 您可以分享应用和项目的愿景，请确保关键项目决策者都有参与进来。请务必涵盖应用的背景和业务目标，以及您规划的开发过程。让每个人更好地了解项目的设计决策和业务方向，这将会有助于降低项目后期出现分歧的风险。
许多供应商将此类简报作为标准的启动信号，请确保您的公司也是这样理解的。
在准备启动简报时，请准备好:
始终对供应商保持清晰和开放的姿态。您作为合作伙伴分享和合作的东西越多，成果就越好。
传达应用的战略意图: 它将会如何适应更为广义上的业务环境。
详细说明您的项目指标: 如用户评级、下载量等。
提供您制定的全部规范和需求，即使它们的完成度暂时还不高，涉及的事项还不具体。
交流有关公司历史和文化的信息。
说明您希望的协同方式，以及您希望的流程。
解释您对关键交付成果的期望，以及各个项目里程碑的时间期望。
确保工作场地
在整个项目中，精准而开放的沟通将确保您获得丰富的信息，以及做出及时的决策，从而创造出伟大的应用。您的供应商可能精通基于不同地点的人员或团体之间的沟通之道，但是，您自己的团队可能还不太熟悉这种工作方式。
面对面沟通的能力是很有益处的，所以请仔细考虑您的团队和供应商之间的互动方式。如果您能够让所有人聚到一起来，那可能是最好的。如果做不到，那么您也应该寻找一个空间，并确保团队成员可以在需要的时候在那里见面。
一件值得确认的事情就是，您的供应商的项目团队拥有专门的办公环境。或者，如果您在您的附近找到了合适的办公环境，请确认一下该团队是否愿意在那里工作。
在为项目团队寻找合适的办公环境时，请问自己:
我们的地点和供应商所在地之间的交通状况是否便利？
我们可以提供或获得一处空间来将我们的项目团队聚集在一起吗？
我们有可用的会议空间吗？我们可以保证它在需要的时候是可用的吗？
如果项目进行中需要改换办公地点，我们是否有时间来重新安置我们的项目团队或代理商的团队？
与多个供应商合作
根据项目的规模和复杂程度，您可能会选择与多个供应商合作。例如，您可能会要求供应商甲来负责构建您的应用，而供应商乙开发后端系统。另外，专门找一家代理商来编写测试脚本、审核代码或执行测试的做法也并不罕见。采用这种方法时，请确定这些代理商之前是否已经合作过，或者他们是否在做特定的事情时更倾向于外包给其他团队。
为了在多供应商协作时确保项目运作良好，您就必须非常清楚这些供应商各自的角色和沟通方式。这有助于让您与供应商之间建立诚实和开放的沟通渠道，让所有参与者形成共识，从而提升您的应用品质。但不要认为这些事情会凭空发生: 您需要对沟通的方式进行监督和管理，确保他们能够培养出彼此信任的文化，而不是陷入业务恶性竞争和相互指责的窘境。
当您准备与多个供应商合作时，请问自己:
我是否准备进行必要的额外管理工作，以确保各团队间的良好合作？
各供应商之间的沟通顺畅吗？
是否有任何迹象表明一个供应商正在争权夺势或试图伤害另一个供应商？如果这种情况确实发生了，我该如何应对？
将成功贯彻始终
一旦项目进入执行阶段，您就要确保您在内部准备、选择供应商和启动项目时所做的工作一直贯穿于项目的执行过程中。
保持开放的沟通
开放式沟通有助于建立信任文化——供应商与您的项目团队之间，以及项目整体与您的利益决策者之间，开诚布公的沟通对创建出的应用的质量会有相当积极的作用。
定期与您的供应商沟通。请做到坦率而诚实，别在不必要的情况下隐瞒可能影响项目或应用的信息。开放而高效的沟通的重要性，无论如何强调都不过分，下面的这些注意事项可以帮到您:
在整个项目进程中继续挑战自我，发展开放式沟通文化，并定期自查沟通状况。
鼓励随时沟通，确保可以通过电话或电子邮件联系到关键人员: 在可行的情况下，给相关人员开放公司门禁。
定期召开会议: 对于许多项目来说，每日电话或面对面进行碰头会议都是有意义的，您可以通过这些会议了解团队的工作方式，掌握进度，并提前知晓那些阻碍项目进度的问题。
改善与远程团队的沟通质量，可以考虑使用 Google Hangouts 等沟通平台。
在进行重要会议时，要将远程团队带到现场。
在项目的整个生命周期内与项目利益相关者保持有效的沟通。这有助于确保满足他们的需求，并且在业务需求有变时使项目顺利推进。
与来自不同国家的团队合作时，请注意处理文化差异和偏见。
定期检查以确保您的团队可以轻松联系到供应商的团队。如果做不到，请寻找改善状况的方法。
制定一个清晰的流程来处理项目需求的变动。
别忘了多借力供应商的技能和专业知识。询问他们，有没有任何沟通方式或技术是他们平时经常采用的，以及采用它们对当下的项目是否有帮助。
当您计划与该供应商进行公开交流时，请问自己:
该机构是否可能开诚布公地与我们分享坏消息？(好消息大家都愿意分享，但分享坏消息其实更重要)
该机构是否可能告诉我们，我们的项目需求是否存在意外问题？
我们如何管理项目中的这些风险？以及，有没有其他新的风险出现？
了解开发方法
应用开发方法为数众多。敏捷 (Agile) 开发是最受欢迎的方法之一，但您也可以使用更多替代方法，它们可能同样适用。所幸的是，您可能不需要担心该选哪个，因为您的代理商可能已经拥有了既定的流程用来进行开发工作。但是，请确保他们的流程:
将用户置于设计过程的中心，且能做到活用用户数据进行洞察和迭代，特别是在设计阶段。
利用开放公开 (beta) 测试 (您可以经由 Google Play Console 对其进行管理)，以便在发布前获取用户的反馈。
您可以询问供应商，过去他们的工作方法遇到了哪些挑战，他们从中学到的经验和教训可以如何应用到当下的这个项目之中。
无论您的供应商使用何种开发方法，请确保其流程和工作实践是清晰明了的，并在所有项目团队成员中达成了一致。
在选择或者调整开发方法时，请问自己:
我所在组织的首选方法是什么？
我是否对双方在该方法内协同工作设定了任何期望？
我的项目团队，包括关键利益相关者和决策者，是否完整地了解了项目流程？
我是否给供应商提供了足够的条件，让他们能够联系到我组织中的决策者？
为改变做好准备
当应用能按照需求文档运行时，很多人会认为这个应用已经 "完工" 了。这是个很诱人的想法，但现实是，任何应用都没有 "完工" 的那天，您总有机会改进它。
当您与用户分享应用设计或进行 beta 测试时，您可能会收到意料之外的反馈。同时，Android 的更新以及新的系统功能也会出现，从而为您提供全新的改进空间。
拥有一个获取此类信息的流程，对其进行评估，并在必要时进行产品迭代，将有助于提供令用户满意的应用。这样一来，对项目时间表和预算的管理也将更有前瞻性。
如果您的组织中没有正式的项目需求变更流程，那么您可能需要去寻求那些已被广泛采用的方法，如 PRINCE、APM、Scrum、Agile 或类似方法。再次强调，别忘了利用供应商的专业知识，并找出他们使用的项目管理方法。更具体地说，您需要询问他们如何建议处理需求中出现的变化。例如，通过开发方法或撰写追加文档来管理需求变更。
当您准备管理项目中的需求变化时，请问自己:
我是否有预算来支持持续的变更和维护？
我是否确保了该应用能灵活应对未来的需求变化？
对于我所在组织中的人员，在应用的第一个版本到来时，以及之后的版本陆续发布时，我是否为他们设立了正确的期望值？
稳健卓越的代码实践很重要
如果一个代码库本身是干净且架构良好的，而且使用的是久经考验的开发模式，那么它将更容易维护，并且在进行更改时不太可能遭遇意外。良好的测试规则也可以通过快速隔离问题来帮助维护代码质量，这样一来，在代码更改方案刚刚出现，且在开发者们的脑中还 "新鲜" 的时候，代码方面的问题就可以得到解决。干净的架构和经过良好测试的代码可以较为轻松地降低以后添加新功能时需要耗费的成本。
测试是应用质量的基础。在项目的不同阶段，测试包含了许多程度不等的措施，从在单一设备上快速检查，到全自动测试都包含在内。严格的测试有助于确保您的代码得到良好维护，防止代码库中那些看似微小的变化在用户那里产生不必要的结果。
从您开始着手设计的那一刻起，就要创建出色的应用架构，然后执行大量的测试。这些测试样例可以作为代码的文档存在。可供遵循的一些最佳实践包括:
为最新版本的 Android 进行开发。
复用经过实践检验的架构和开发模式。
在设计和开发过程中加入可用性测试。
确定目标用户群体中最受欢迎的设备，并首先测试这些设备。然后尽可能扩展测试设备范围。
使用 "牙刷测试 (toothbrush test)" ，我们要求所有 Google 产品都通过这个测试: 如果应用就像牙刷一样每天都被使用至少两次，那么用户是否会随着时间的推移产生越来越大的沮丧情绪。
从一开始就努力追求持续卓越的产品。
您也可以向您的供应商询问以下内容:
您将如何为我们的应用确定合适的开发模式？
您做了什么样的可用性测试？您如何进行可用性测试？您打算使用哪种测试框架？您能举例说明您成功执行了可用性测试吗？
您是否计划使用测试服务，例如 Firebase Test Lab？
您计划进行多大程度的自动化测试？
您进行这些测试的频率是多久一次？
您打算测试哪些设备 (包括平板电脑)？报价中包含哪些测试 (例如单元测试) 以及可能的附加内容？
您是否拥有测试设备库？这个设备库里的设备型号在当下是否有代表性？您是否希望此项目向库中添加新设备？如果您负责这些额外设备的采购，那甲方是否会在项目完成后拿到这些设备？
您是否能够提供任何保证，例如在3个月内修复错误？这一条比较适用于固定价格合约。
您将如何处理回归测试？
同时，问问自己:
我想要什么样的测试报告？
我应该让第三方审查代码的注释和文档，以确保未来的可维护性吗？
我们如何处理集成测试？
我们如何处理用户接受度测试？
我们是否想要或需要维护我们自己的测试设备库？
如果上面这个问题的答案是 "是" ，那么我们要如何维护最新的测试设备库？
在产品上架前进行测试
通常，您只有一次机会来让用户满意。邀请一些受信任的早期用户进行封闭测试可以验证您之前对产品做出的假设。这些测试通常有助于发现内部测试中遗漏的错误。通过在您公开发布应用之前进行测试，并推出应用的营销活动，您可以增加应用首发成功的机会。
Google Play Console 中包含的功能可以在这个阶段提供帮助:
内部测试，您公司内部的人员可以测试并提供反馈。
封闭式或 alpha 测试，您可以严格控制谁有机会测试您的应用。
开放式或 beta 版测试，您可以向 Google Play 商店中表示有兴趣测试新应用的用户提供应用。
您可能还想申请 Start on Android，只要您的应用处于发布前测试状态，就可以通过 Google Play 上的 Early Access 专区为您的应用提供曝光机会。
Start on Android:
https://developer.android.google.cn/google-play/guides/startups/
在运行测试时:
从您所在组织的社交网络中寻找合适的测试人员; 寻找忠诚的用户和批评者。
考虑一下您希望让 beta 测试达到怎样的严格程度: 如果您只想让选定的用户参与，请运行封闭式测试，如果您觉得任何对应用有兴趣的人都可以参加，那么请运行开放式测试。
考虑限制开放式 beta 测试中的参与者数量，以确保测试处于可控状态。
除了测试人员的直接反馈，还要监控 Android vitals 提供的应用性能表现指标。
使用 Google Play Console 的分阶段发布功能，逐步向更多用户发布更新后的应用。监控任何可能存在的问题，如果出现预料之外的问题，就暂停发布，并纠正问题。
当准备测试您的应用时，请问自己:
我的组织是否支持并已准备好与供应商一起进行分阶段发布，并进行封闭或开放式的测试？我的团队是否需要做一些内部培训才能完成这个任务？
我们是否拥有将用户置于设计中心并能充分利用测试的文化？我们怎样才能将其融入我们的工作方式？
分享 Google Play Console 帐户权限
您可能希望供应商处理 Play Console 测试、应用发布、回复应用评论、分阶段推出等问题。您可能还想与他们分享应用统计信息和收入信息。
但是，您的 Google Play 帐户是宝贵的资产，通过在 Google Play 帐户中将该供应商权限设置为 "用户" ，您可以完全控制自己的帐户。但请记住:
只有在需要访问权限时才将供应商或您自己的员工添加到 Google Play Console，不要因为该人员 "可能会需要访问" 就添加该用户。
如果您正在和多家供应商合作研发多个应用，请为每个应用单独设置权限。
写在最后的一些话
与供应商合作开发您的应用是一种有效的工作方式，但是请记住，第一版应用的交付并不意味着您的项目已经完工了。随着组织的发展或产品阵容的变化，您需要响应用户提出的需求并持续改进您的应用。应用交付只意味着一个新的开始，并不意味着应用开发工作的终结。
希望本系列文章中的建议能够帮助您更轻松地找到合适的供应商，并在应用开发项目中取得成功。
您对外包应用开发有什么看法吗？请在下面的评论中告诉我们。我们希望您能活用本次连载中提到的知识，顺利找到合适的伙伴，并尽快在产品和商业层面上取得成功！
推荐阅读